#[derive(Clone)] on Component{Info,Descriptor}
#9812
Conversation
alice-i-cecile
added
A-ECS
There was a problem hiding this comment.
This likely isn't too big of an issue, but a lot of the type safety and soundness of the ECS is heavily reliant on these being correct. We currently do not expose a way to mutably accesss these from Components, but a lot of care should be taken to ensure that the ability to clone them doesn't cause any potential safety footguns, both internally and externally.
I'll give this a more thorough sweep later.
alice-i-cecile
removed
the
S-Ready-For-Final-Review
|
My one worry is the drop function stored on |
|
Yeah, and you already had access before, this just lets you have owned access without having to borrow the |
alice-i-cecile
added
the
S-Ready-For-Final-Review
There was a problem hiding this comment.
We don't expose a &mut Component{Info,Descriptor} of any kind, and this does not change the status quo.
This does re-raise the old concerns I had with @maniwani's "components as entities" idea, however. Not sure if they have any comments on this change.
I don't see an issue. The only thing that would raise safety concerns is the user being able to modify the data in |
|
OK sounds good to me then. Merging. |
# Objective Occasionally, it is useful to pull `ComponentInfo` or `ComponentDescriptor` out of the `Components` collection so that they can be inspected without borrowing the whole `World`. ## Solution Make `ComponentInfo` and `ComponentDescriptor` `Clone`, so that reflection-heavy code can store them in a side table. --- ## Changelog - Implement `Clone` for `ComponentInfo` and `ComponentDescriptor`
Objective
Occasionally, it is useful to pull
ComponentInfoorComponentDescriptorout of theComponentscollection so that they can be inspected without borrowing the wholeWorld.Solution
Make
ComponentInfoandComponentDescriptorClone, so that reflection-heavy code can store them in a side table.Changelog
CloneforComponentInfoandComponentDescriptor